BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / wildcat / bikit32s.zip / BIKITTY.DOC < prev next >

Wrap

Text File | 1992-05-25 | 19KB | 381 lines

B i K i t t y Version 3.2 WILDCAT 3.xx AND BIMODEM INTERFACE HELP DOC'S -------------------------------------------- If you have used Bimodem, you know it is a powerful file transfer protocol that allows you to upload and download at the same time, essentially doubling your throughput. BiKitty will interface Bimodem to Wildcat so your users can enjoy this terrific protocol on your Wildcat system. Well....so far BiKitty seems to be the BiModem Interface of choice among most Wildcat sysop's. I created BiCats to allow BiModem and Wildcat to co-exist together. With the inception of Wildcat 3.xx the hook for BIMODEM in the external protocol directory was removed by MSI. I am not sure if they will ever add this hook back at present. Of course BiCats works just fine as a File Menu Dos Hook, and I am really glad MSI offers this feature. But there are a few sysop's out there that really miss having BiModem as a external protocol from the protocol menu screen. It is for you folks that I wrote BiKitty. BiKitty is quite different from my BiCats in that it marries BiModem and Wildcat together in a different way. I'll try to explain. BiKitty has four parts PREBICUP, AFTBICUP, PREBICDN, and AFTBICDN. These are called from the batch protocol file either BIMODUP.BAT or BIMODDN.BAT. Here how it works...pay close attention! USER DOWNLOAD SESSION: The user marks off what files they wish to download via Wildcat's file marking system. They may also enter the file(s) via the Wildcat routine that asks for the file(s) to download one at a time. Just as they would with any other protocol. They then select to download and are offered the protocol menu screen. They select [B] for BiModem and away we go..... The BIMODDN.BAT batch file first calls PREBICDN.EXE which prompts the user for an area to upload to (that they have security for) and writes two files...BIMOD.### (Area chosen by user) and BIMODEM.### (which is the pointer file for areas that they have security to download from). It will create these files in the Node's EP directory. It will then write this info to the Bimodem.Cfg file that you point to on the command line. It will then instruct the user they have X amount of seconds to start the BiModem transfer on their end. BIMODEM will then run and create a BIMODEM.LOG and download the files selected by the user automatically. The user only has to configure there BiModem transfer list for the files they want to upload. This will save the user time and effort, and makes it feel more like any normal protocol they would use. ************************************************************************ *Special Note* At present the internal code in Wildcat prevents me from updating the user's upload or download count and kilobytes. This is something for which I am not responsible, nor can I change. Wildcat version 3.50 will have this problem corrected at which time my utilities will be able to update the user record properly. ************************************************************************ AFTBICDN.EXE will then be called in the batch file and read the BIMODEM.LOG and BICAT.### files and add whatever files where uploaded during the download session to the Wildcat database. It then updates the user record for files uploaded and extra time allotted. Wildcat will take care of updating the user and file database for files that where downloaded. Again....as stated above in the special note Wildcat doesn't allow me to update the user's record. This is part of the hard code and will be changed in Wildcat Version 3.50. USER UPLOAD SESSION: The user selects the area to upload to via Wildcat as normal. Then WC! will ask for filenames, descriptions, passwords, keywords, and additional info as it does for any protocol used. The user then selects [B] BiModem from the protocol menu as transfer type to use. The BIMODUP.BAT batch file first calls PREBICUP.BAT which sets up the BiModem.Cfg file for the proper path to the node's EP directory. It also writes time allowed, port number, speed and so forth. They will be told they have X amount of seconds to start the BiModem transfer on their end. BIMODEM will then run and send whatever files the user has configured in thier transfer maintanence list to the node's EP directory. It will also allow them to download any files they have configured thier transfer maintanence list for that they have security access for. BIMODEM will create it's BIMODEM.LOG after the transfer is done. AFTBICUP.EXE will then look to see if any downloads occured during the session and update the user and file database with the information. Wildcat will then check the uploads as it does normally and transfer them to the directory chosen by the user at the onset of the session. The user should configure their uploads and downloads in their BiModem transfer list before starting the session. The user will not be able to add files to the upload during the session as they can with regular BiCats because Wildcat will not know that more uploads than those listed by the user at the beginning of the session exist. Again....as stated above in the special note Wildcat doesn't allow me to update the user's record. This is part of the hard code and will be changed in Wildcat Version 3.50. In a nut shell...it's kinda like merging BiCats and Wildcat together into one package...simply called BIKITTY. SETUP Setting things up is simple, and we'll go through it step by step. USE A WORK DIRECTORY FOR YOUR UNARCHIVING OF FILES Create a new directory to work in. This keeps things much easier to follow along with and clean up afterwards. Ok, here we go. 1. Take all the .COM files from the Bimodem archive (BIMODxxx.ZIP) and put them in any directory that you have your dos environment 'path' set up for. Type 'set' at the dos prompt to check. I set everything into a directory called c:\wc\ep and include it in the path statement in my autoexec.bat. * Note: You need to be using BIMODEM version 1.24 or above! 2. Do the same thing with the *.EXE files from this (BIKITxxx.ZIP) archive. All the files should now be available in the path. 3. Place the copy of BIMODEM.CF1 I have included into each of your node home directories. IE: c:\wc30\wcwork\node1, c:\wc30\wcwork\node2, etc. Also place a copy of the BIKITTY.SCR and BIKITTY.BBS into the node home directory too. 4. In each directory that you put a copy of BIMODEM.CF1, run BICONFIG /C BIMODEM.CF1 to make changes necessary for your system. The copy I have included is a regular setup and should not require much modification, except for 'Filenames and Paths'. Make changes to this section as follows. Remember to run BICONFIG from the node's home directory! You should refer to the BiModem Docs for further information regarding BiModem's option settings. A. 'Directory that files will be received into' should be left blank. BIKITTY will do all that work for you for each caller engaged in a BiModem session. B. 'Directory that aborted files will be renamed into' should also be left blank. C. 'Delete aborted destination files (Y/N)' If you create a sub directory off your node's EP directory called ABORT then you may set this to N. If you do this Bimodem will allow for recovering transfers. Aborted file transfers can be continued at a later date if you wish. The aborted transfers will be placed into the sub directory \ABORT until completed. If you choose not to use this function then set your answer to Y. D. 'List of directories that determine rejections' should be the name of a file that lists every directory that holds files you don't want someone to try and upload again. To make BIMODEM.REJ, list all file directories in it, in the form; c:\-\1 c:\-\2 c:\-\3 etc., where each line is a directory that holds files you don't want duplicated. Note that this is an ASCII file. BIMODEM.REJ should point to your HOME directory. IE: C:\wc30\bimodem.rej That is also where you should create the file at. If you put all of your file areas in this list, then BiModem will prevent any duplicate files from being uploaded. E. 'Directory or list of directories that files are sent from' should be the path to your Node's EP directory (c:\wc30\wcwork\node1\ep\, or whatever) and file name BIMODEM.001 (if node 1, 002 if node 2, and so on). BIKITTY will build the actual file for each caller, based on their security access as defined in the Wildcat system files. F. 'Path to password' should be the complete path and name of the password file (PASSWORD.TXT) generated by BIPASS.EXE. This should point to your Wildcat home directory; c:\wc30\PASSWORD.TXT. Which is where BIPASS.EXE must be run from in order to work. It is a list of any files that you have online that are password protected. G. 'Path to Upload/Download' should be left blank. H. 'Path to default files list for BiList' should be the path and file name to your ASCII file list for the bbs, if you have one IE: C:\TEXT\FILELIST.BBS. Preferred format for this file is a single line per file listed. I. 'Path to log file' must be left blank. J. Connections/disconnections should not be logged. K. File transfer statistics should not be logged. 5. BIKITTY will write to the Bimodem.Cf1 file when it is run, and supply the connection info (port and speed), their max download bytes for the day, time left, along with the information of the user's selected upload area. The rest of the options are up to you the sysop. (see the bimodem documentation for more detailed information). 6. Complete steps 4.A through 4.K for each one of your nodes if you are multi-node Wildcat. 7. Copy the enclosed BIMODDN.BAT and BIMODUP.BAT batch files to your home directory. Then change to the home directory. Edit whatever you need to on the batch files I have included for operation on your system. 8. Run Makewild (still in the home directory) and go to the External Protocol section. Add BiModem to the external protocol menu as such: [B] BiModem BIMODUP.BAT BIMODDN.BAT Y * Make sure you set the Wildcat Node Id and Port Id in the batch file that calls Wildcat for each node used. This should be in your Cat.Bat file that calls the node for operation. You should also set enviroment variables NODEPATH & HOMEPATH. NODEPATH is the full path plus a trailing backslash of your node's directory. HOMEPATH is the full path plus a trailing backslash of your home directory. IE: Set WCNODEID=(node you are on ie: 1) Set WCPORTID=(port you are using on that node ie: 1) Set NODEPATH=(ie: C:\WC30\WCWORK\NODE1\) Set HOMEPATH=(ie: C:\WC30\) * Remember the ending backslash on the directories above! ************************************************************************* * I now look for 2 more environment variables for the comm routine. * * They are WCIRQID and WCBASEID respectively. If they are not set in * * your cat.bat file that starts the node then I default to the settings * * in your MakeWild.Dat. * ************************************************************************* * BiKitty.Exe offers file virus scanning via ScanFile.Bat If BiKitty finds the file "SCANFILE.BAT" it will shell to EMS or DISK before adding the file to Wildcat's database. ScanFile.Bat will do it's normal job of scanning the file. If the file fails, BiKitty will add it to the database with the failed scan flag set to Y. It will also subtract the file and upload kilobytes from the users record. At present the only scanner I can verify operation of with BiKitty is CatScan. Others might work but have not been tested by myself yet. If you are going to use another utility in your Scanfile.Bat file along with your scanner then follow this simple rule. Change back to the Node's directory at the end of the batch file. The following example will help you to understand what I mean: cd\wc30\wcwork\node%wcnodeid% catscan %1 cd\wc30 { some other utility autodesc, etc. } cd\wc30\wcwork\node%wcnodeid% If you are not running someother utility after your scanner then you don't have to worry about changing back to the Node's directory. ********************************************************************* There seems to be afew of you out there who use a autodesc type utility. This will work as long as the user selects upload from WC! as opposed to download. Remember...during an upload selection I let WC! do its normal routine. ********************************************************************* Bikitty has some new features, they are as follows: Long Descriptions - If download is selected through Wildcat and your virus scanner is capable of extracting a SDI or DIZ file from the archive and putting it in the node's home directory then BiKitty's AFTBICDN.EXE will read that file and add the text to the uploaded file's long description. *.SDI or *.DIZ is created by the user and is a standard ascii file that consists of up to 15 lines (79 chars max each) of text. KeyWords - AFTBICDN.EXE now also asks if the file should have KeyWords. If the user selects N then no KeyWords are added to the uploaded file. If they select Y then they will be prompted for up to 6 keywords (10 chars max each). Both AFTBICDN.EXE and AFTBICUP.EXE will display the file(s) BIKITTY.SCR (if color on) or BIKITTY.BBS (if color off) at the end of each session. ┌──────────────┐ │ UPLOAD NOTES │ └──────────────┘ Through the use of PREBICDN.EXE, a single selectable upload area is supported, so the user may upload to an area of their choice that they have access to normally. All uploads that occur during any one session will go to the area that the user so chooses, they will only be allowed to choose areas for which they have security for. This means for each BIMODEM session they can select the area they want to upload too. Save Upload's to Which Area ("?" for Choices) ? [1] New Uploads [26] Sysop Only! They will only be shown areas for which they have security for in WC! * When download is selected Wildcat sends a message to the user to start thier transfer now! This occurs before the user is prompted to select an upload area by BiKitty. I explain to the user that if they are using BiModem to wait to select the upload area before starting thier transfer in my PREDOWN.(SCR/BBS). ┌────────────────┐ │ PASSWORD NOTES │ └────────────────┘ BIMODEM determines if a file is Password protected by the PASSWORD.TXT file. If the file is password protected then the user must enter the file they wish to download with their BIMENU as FILENAME,PASSWORD as opposed to just FILENAME. If the Password is correct then WILDCAT will let BIMODEM download the file, if not...well it won't let them! This works the same for Uploads, if you wish to upload a file that is password protected then do it just as you would to downloading it, except in BIMENU you would be using the "U" instead of the "D". The utility needed to make the PASSWORD.TXT file is called BIPASS.EXE It MUST be executed from the Home directory. Where it will make a list of all files that you have that have a password attached. If you have selected to show password protected files in Wildcat then you should place this command as part of your PostCall.Bat and run it after every caller. This will make a new PASSWORD.TXT file after every caller. Otherwise once a day should be suffient to provide adaquate security for your files. MOST COMMON PROBLEMS #1. Passwords fail due to improper entry into BiMenu. You need to use the format: FILENAME,PASSWORD Please remember that the password following the comma must be in CAPS! So there you have it in a nut shell. It is easy to setup and totally worth the effort!!!! If you should have any questions please feel free to call me and I will help you out. I can be reached at my BBS from 8:00pm till 8:00am (East Coast Time), Which at present is the only hours my bbs will be up and running. PLEASE do not call anytime other than the hours specified until I get another phone line installed. The BBS # is (717)-731-8299 (19,200 V42/Bis) Good Luck and thanks for supporting BICATS, BIKITTY, BIMODEM & WILDCAT! Enjoy! 05/24/92 Dale Fedorchik The Cat's Castle BBS Warranty This is product is provided "as is" without warranty of any kind. The entire risk as to the results and performance of the program is assumed by you. Futher more, I the author do not warrant, guarantee, or make any representations regarding the use of, or the results of the use of the program, and you rely on the program and results solely at your own risk. I the author cannot accept responsibility for system damage, loss of profit, or any other special, incidental, or consequential damages resulting from the use or inability to use this product.